IBIS Macromodel Task Group Meeting date: 28 May 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Michael Mirmak requested that we add a new item to the ATM agenda's Topic bin list: Do we need to mention in the spec, or require, digital signing of the AMI .dll and .so files? Arpad added the topic to the list, and Michael M. said we could discuss it when we have a chance. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the May 21 meeting. Michael M. moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- New Discussion: Complex C_comp modeling: Randy summarized the changes in the most recent draft, which he had emailed to ATM on May 20th. - Definition of this Issue: section. - changed: " ... modeling of effects such as frequency and voltage dependencies." to: " ... modeling of effects such as frequency dependency." - This change was based on comments from Radek during earlier discussions. Radek has asked about "voltage dependencies" and whether they could really be modeled with subcircuits restricted to using IBIS-ISS components. - On page 117 (IBIS 7.0), add [C Comp Model] to the list of keywords and parameters that may be omitted from a [Model] using [External Model]. - Add A_gnd as a valid terminal type. - During the last discussion it was decided that there's no reason to exclude A_gnd in this proposal when it's supported in BIRD189 syntax. - Changes to the [C Comp Model] Figure. - Clarified the Si_location & Timing_location (changed arrow location). - Removed "input" triangle that had caused confusion. - Explicitly show ***_ref terminals at the buffer. Terminal names are consistent with BIRD189. - Bob asked if Ext_ref could also be added to the figure. Randy agreed. Arpad asked about the draft's use of [C_comp Model]. He noted that spaces and and underscore '_' characters are interchangeable in keywords, and keywords are case insensitive. Bob noted, however, that they had standardized on using spaces instead of underscores in keyword names in the spec itself. Randy noted C_comp is used in the spec, and Bob/Arpad noted that C_comp is a subparameter not a keyword. Randy agreed to change instances of the keyword [C_comp Model] to [C Comp Model], which is consistent with the style used for the keyword [C Comp Corner]. Bob asked how different IBIS-ISS files could be used for the different modes. Randy noted that the proposal allows two instances of [C Comp Model] to appear in each [Model]. Randy said it might be helpful to have two example [Model]s, one which contained Driving and Non-Driving Mode [C Comp Model]s, and a second example that used a single [C Comp Model] with Mode All. Bob agreed, and Randy said he would update the Examples: section. BIRD197.3_draft_4(DC_Offset): Arpad summarized the state of the discussions and the disagreements from previous meetings, and he shared Fangyi's latest email dated May 28th. Walter noted that he agreed with Fangyi that there were two mathematically equivalent approaches (2.1 and 2.2 in Fangyi's email). Walter said the standard currently uses 2.1, so why should we change it? Walter said there is no need for the Rx GetWave() to output anything differently than it does now. Radek asked how hard it would really be for the EDA tool to deal with it if GetWave() returned a waveform with a non-zero DC offset. Walter noted that DDR5 is the only single-ended technology that currently needs AMI model support. He asked why it required any changes relative to the SERDES channels AMI supports. He noted that the JEDEC DDR5 standard describes a differential receiver, after which the signal is differential like what we deal with in SERDES, and the summer is driven by latches that are differential and have no "threshold" value. They're differential latches, >0 is called a 1, <0 is called a 0. So, the "waveform at the latch" is differential. Walter noted that there are some subtleties related to the granularity of the register used to set VrefDQ. This granularity could lead to some small (order of a few mV) uncertainty in correcting for the DC offset, so the waveform at the latch might have a small DC offset from 0. But he noted that could already be handled by the current AMI standard, as that offset could be left in the waveform returned by GetWave(). There's no need to introduce another offset or threshold. Ambrish noted that the definition of the wave parameter in AMI_GetWave() (page 207, IBIS 7.0) discusses NRZ and PAM4. He noted that we might need to add a discussion of single-ended support. He noted that the language describing NRZ (assumed to be differential) discusses small offsets and "nominally centered around zero volts," which does align with Walter's description of the small residual offsets based on the VrefDQ register settings in DDR5. Arpad noted that further discussion will be needed. - Curtis: Motion to adjourn. - Michael M.: Second. - Arpad: Thank you all for joining. AR: Randy to update the C Comp Model draft with today's discussed changes and send it to ATM for review. ------------- Next meeting: 04 June 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives